讓我們來打鐵趁熱的討論一下 MVP vs 技術債 這項主題吧～
之所以會有這個主題的發想源自于，我轉職 scrum master 後，接觸到了不同的開發團隊、體驗到了不同的團隊文化...

某一張單在開發到第二天的時候發現 SQL 效能有問題，並且直接找 PO 與主管討論後決定大動干戈進行翻修改寫...

結果到了最後當然就是一個完整的人力卡在那裡，整體 Sprint 的執行狀況也是很糟。
所以這邊就想跟大家來討論一下 MVP 與 技術債

那什麼是 MVP 呢？

MVP:

在 D6 - 那些敏捷日子_PO你可以硬一點嗎？(下)時有簡單跟諸君帶到 MVP 這個名詞與他簡單的一些概念。
那到底什麼叫做最小可行性產品以及他的優點是什麼呢？

舉個我很自豪對於 mvp 取捨的案例，當初 stakeholder 信誓旦旦的來跟我討論 (當時還是 PO)

直播就是趨勢，我們網站也來一個直播功能吧！！

照傳統的玩法，我們可能就要開始研究說串流該怎麼處理。又或著是說找找有什麼雲服務可以來提供直播串流服務，我們來研究一下它們的 SDK 套件看能不能使用在我們的前端技術上。
雖然我對我們團隊的技術有信心，但要做完感覺也不是兩三個月就可以穩定運行的...
且也沒人能保證 直播功能真的是我們網站用戶需要的

所以後來我們訂定最小可行性產品的方式為：

1. 找到一家口碑還不錯的雲服務商(平台)
2. 串接雲平台的直播場次資訊，並且寫一個報名功能
3. 登入我們網站並且報名完成後，跳轉到平台頁面觀看直播

這下有效的讓開發時程壓短至一個 sprint，並且及早的投入市場。
去驗證看看網站使用者是否真的買單直播功能(而非投入大量人力後)

不過要制定 MVP 還是有點難度的，

尤其是在於前面需求發想時，不斷地要我們拿出最天馬行空，並畫著最大的餅，最完美的功能。
但這邊又要求在制定實際完成計畫時則是以減法來看。
這邊處理久了還真的會有一點精神分裂勒哈哈

至於如何在 MVP 與技術債之間抉擇，我相信諸君心裡應該有個想法，
不訂閱一下這系列，明天再來看看
D10 - 那些敏捷的日子_MVP vs 技術債 (抉擇篇)
謝謝

拆成上下兩篇這招，真的是一直用一直爽哎
只能說真的在寫文章的時候與計畫中差很多呢！(直播的 case 本來打算獨立篇幅來分享)

參考資料：
無